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data for an MES application model object. The data for 
the model object is held in a database. To export infor- 
mation, the database definition is used to construct XML 
tag information and the database values are used to con- 
struct XML element contents. To import information, 
the XML tag information is used to construct database 
references, and the XML element contents are used to 
load the database. To export information, database ad- 
dress information names are used to form XML tag la- 
bels, and the model object data in the database is used 
to form XML element contents. New classes are cre- 
ated that are derived from the model object class. The 
new classes inherit the functionality of the model ob- 
ject classes but they also include new import and export 
methods that effectively wrap, or layer, the import or 
export logic around the model objects. DTDs may be 
used to validate XML documents that are exported or 
imported from such a system. Code generation facil- 
itates the creation of the new class definitions and the 
DTD. The code generation considers the database meta- 
data in generating the code. 
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System and Method of Exporting or Importing Object Data In 
a Manufacturing Execution System 

Background of the Invention 

1. Field of the Invention 

This invention relates to Manufacturing Execution Systems (MES) and, more 
particularly, to importing and/or exporting MES model object data. 

2. Discussion of Related Art 

Modern manufacturing facilities that manufacture semiconductor and other 
complicated components use Manufacturing Execution Systems (MES) to record and 
coordinate manufacturing events in real time. Among other things, these systems 
integrate and manage information generated by various activities and automated systems. 
MES functionality includes (1) batch/lot management, (2) real-time operations 
management, (3) quality management, (4) resource management (including scheduling, 
dispatching, equipment monitoring, and preventive maintenance), (5) direct and indirect 
labor coordination and dispatching, (6) specifications and work instructions, (7).recipe 
management, (8) detailed material control and genealogy, (9) actual cost tracking, and " 
the like. 

An MES, at some level of abstraction, models the manufecturihg operations that 
it helps monitor and coordinate. An MES is typically an object-oriented application that 
often exposes the behavior of the application, and specifically the application's objects, 
through an interface. The modeling effort is costly and time consuming but highly 
important to the success of the MES. Because these manufacturing operations and 
related activities tend to be complex, many modern Manufacturing Execution Systems 
employ databases to hold various types of object data. Moreover, standards have been 
developed to describe, at some level of abstraction, the interfaces to the MES 
components. For example, CIM is a standard known in the MES art for describing a 
model of the structural setup of a manufacturing operation, e.g., machines, materials, 
how to process materials, and the like. 
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Many modern manufacturing companies first create a "development" system 
when considering a new manufacturing line or portion thereof. These development 
systems often include similar physical components and systems to the eventual, desired 
production system, including for example the same or similar MES. The development 
system is used to construct, test and tune a model in the MES. 

Often, however, the production system (or target system) differs from the 
development system in some aspects. For example, the production system may use a 
certain physical component that has a corresponding physical component in the 
development system but the development component and the production component 
differ in some attributes, e.g., execution parameters. Sometimes this difference is 
inevitable because the production components are too scarce or expensive to use in a 
development system. Alternatively, the production component may not yet exist in a 
"released" form, yet manufacturers nonetheless benefit from creating and modeling a 
production system in anticipation of its eventual release. Consequently, though a 
development system is often similar to an eventual production system, invariably some 
differences exist. 

Typically, migration of the data from a development system to a production 
system is ad hoc and relies on the use of a skilled technician. The technician must first 
understand an interface to the MES of interest, e.g.., the one from which data is to be 
exported from, and then he or she must write some form of script to invoke the model 
objects to obtain the data. This approach is time consuming, costly, and error prone. 
Moreover, if the model changes, the script may no longer work (e.g., it may refer to now 
non-existent or changed objects). 

Summary 

One aspect of the invention uses XML to express model object data for an MES 
application model object. The data for the model object is held in a database. To export 
information, the database definition is used to construct XML tag information and the 
database values are used to construct XML element contents. To import information, the 
XML tag information is used to construct database references, and the XML element 
contents are used to load the database. 
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Under another aspect of the invention, logic parses an XML expression and 
converts XML tag labels to database address information, and converts XML element 
contents to database values. 

Under yet another aspect of the invention, a class is derived from an MES model 
object class, and the class so derived inherits all functionality from the MES model 
object class. The class further includes import method logic to receive an XML 
expression of model object data and load the XML-expression of the data in the 
database. 

Under another aspect of the invention, a class that is derived from an MES model 
object class, and the class so derived inherits all functionality from the MES model 
object class. The class further includes export method logic to create an XML expression 
of model object data in the database. 

Under another aspect of the invention, data may be imported into an MES 
application having at least one model object, by forming an XML expression of the 
object data. The the XML expression is sent to the MES application, and the MES 
application parses the XML expression to determine the object type, the object parts, and 
the object data values. The MES application loads the determined object type, the object 
parts, and the object data values into a database corresponding to the MES application. 

Under another aspect, a DTD expression of the object class definition is formed 

and the 

XML expression is validated against the DTD expression. 

Under another aspect of the invention, import logic is layered over the model 
object, and the import logic defines an external interface for loading model object data. 
The import logic includes logic to invoke the model object to load the model object data 
into the database. 

Under another aspect of the invention, export logic is layered over the model 
object, the export logic defines an external interface for obtaining model object data. 
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The export logic includes logic to invoke the model object to obtain the model object 
data from the database. 

Under another aspect of the invention, a MES includes a client and server 
computer. The client has a user interface control for exporting or importing selected 
model objects of the MES and for constructing a client request to request export or 
import of selected objects. The server has the MES application executing thereon. The 
MES application is organized as a relationship of model objects, with each model object 
having data therefor stored in a database. The application includes import and export 
logic, responsive to the client request, for forming an XML expression of model object 
data in response to an export request, and for loading data expressed in XML form into 
the database in response to an import request. 



Brief Description of the Drawing 
In the Drawing, 

Figure 1 is an architectural diagram of a preferred embodiment of the invention; 

Figure 2 is a flow chart showing the logic for exporting information according to 
a preferred embodiment of the invention; 

Figure 3 is flow chart showing the logic for reading information from a database 
and writing an XML-based version thereof according to a preferred embodiment of the 
invention; 

Figure 4 is a flow chart showing the logic for importing information according to 
a preferred embodiment of the invention; 

Figure 5 is flow chart showing the logic for reading information from an XML 
document and writing corresponding information to a database according to a preferred 
embodiment of the invention; 

Figures 6A-6B show class and object expressions for layered export and import 
software of a preferred embodiment; and 
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Figure 7 is a system diagram of exemplary hardware for a client or server 
computer according to exemplary embodiments of the invention. 



Detailed Description 
Overview 

Preferred embodiments of the invention facilitate the exportation and importation 
of MES objects modeling a manufacturing environment A model object may contain 
many parts, such as product, material, lot templates linked to process flows, and the like. 
Likewise, the model information may define the data interrelationships. In one 
embodiment, though the MES model is object-oriented, the data for the various objects is 
held in a table-based database, such as ones available from Oracle Corporation. 

A preferred embodiment of the invention facilitates importation and exportation 
of model data by layering importation and exportation logic over the model. In this 
fashion, the importation and exportation logic works, even if the underlying model is 
changed. That is, no tools need to be redeveloped or modified because the model 
changes, and system administrators do not need to track model changes to ensure that ; • 
importation and exportation functionality works. 

Other preferred embodiments use a human readable representation of the model 
object data to facilitate exportation and/or importation of model data. For example, 
extensible markup language (XML) may be used as described below to describe the 
model object data as an XML document. A metadata-like description of database 
information and of the model object class definitions may be defined as a Document 
Type Definition (DTD). (Both XML and DTDs are known and described by w3c and 
other organizations.) The use of XML and DTDs facilitates exportation and 
importation of model object data in several ways. For example, because meaningful 
markup tags are used, the data in the XML document is self-describing and easier to 
comprehend by humans and/or tools. Moreover, the use of DTD facilitates the use of an 
XML document by defining valid structure so that XML documents may be parsed to 
test their structural validity. Moreover, XML and DTDs are based on well defined 
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standards, and thus tools may be more easily developed to modify or create information 
to be imported and/or exported from a system. 

In short, under the principles of a preferred embodiment, a user identifies MES 
model object(s) of a source environment to be exported (e.g., specific instances or all 
such objects) and, through a graphical user interface (GUI), may requests that it (they) be 
exported. Software, layered over the model objects of the source environment, responds 
by reading and extracting the relevant information from a database holding the object 
data and writing the information into an XML document having a DTD corresponding to 
the selected object class definition. The XML document may then be accessed and/or 
modified with other tools. For example, an XML editor may be used to view exported 
information and to allow a user to modify that data as necessary so that it may be 
imported into another system. Alternatively, other tools may construct XML-forms of 
information that should be imported, or loaded, into a target system by referring to a 
DTD that defines the structure of data that may be imported into a system. In any event, 
an XML document may be used to hold object data to be imported into a target 
environment. Other software, layered over the model objects of the target environment, 
read the XML information, effectively deconstruct it into its parts, and load the 
information in the target database. The DTD may be used to provide one measure of 
information validation (i.e., DTD validation against the XML document, as known in the 
art) before subsequent database validation by the target system. 

Architecture 

Figure 1 shows an exemplary system on which preferred embodiments of the 
invention may be manifested. A client computer 102 may communicate with a server 
computer over a communication network, represented collectively by the paths 106, 108, 
110, and 112. 

The client 102 includes a browser 1 14. In one embodiment, the browser is an 
Explorer browser, available through Microsoft Corporation. This one embodiment uses 
an ActiveX control (implemented with conventional technology available through 
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Microsoft Corporation) to provide certain GUI functionality described below. Though 
no arrow is shown between the Active X control 1 16 and the browser 1 14, these two 
components cooperate in a known way. Other browser and GUI control techniques may 
be substituted under the principles of the invention without loss of generality. 

The server 104, as shown, includes a first application 1 18, a second application 
120, and XML access application 122, and at least one active server page 124. The first 
application 118 operates with a first database instance 126, which for purposes of this 
description can be considered as a source database instance, representative of a 
development environment. The second application 120 operates with a second database 
instance 128, which for purposes of this description can be considered as a target 
database instance, representative of a production environment. The first and second 
applications 1 1 8, 120 and the XML access application 122 all may communicate with at 
least one XML document 130, which may be manifested as a file, though it also may be 
manifested in other forms. The active server pagel24 provides one way (not the only 
way) to access the server applications 118, 120 in response to commands from the 
browser 1 14. Figure 1 among other things illustrates that information may be exported 
from one type of MES application 118 and imported into another 120 on the same 
server, but it should be appreciated that the various applications shown on the one server 
may, and indeed are expected to be, distributed among several servers. For example, 
each MES application may have its own server. 

The first and second applications are object-oriented MES applications 
constructed according to conventional techniques. The actual type of MES applications 
and their MES functions are not material to the invention and thus their detailed logic is 
not described. In one embodiment, the MES objects (also referred to herein as model 
objects, or domain objects) are constructed as COM + components with published APIs. 
(COM + is a known approach of expressing object behavior and interfaces.) The MES 
object data is held in persistent form in the corresponding database (e.g., application 118 
has data in database instance 126). 

In one embodiment, the database instances 126, 128 organize model object data 
as tables. For example, visualizing a simple table, the leftmost column may correspond 
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to a class, and each column may correspond to a member of the class definition. Each 
row in the exemplary table would then correspond to an object instance, in which the 
actual values for a given row and column correspond to that instance's member's value. 
Naturally, the data relationships may define further levels of hierarchy and references as 
is known in the art. The operative issue is that the metadata of the table definitions 
corresponds to MES model class definitions and that mechanisms are known for getting 
and setting object information held in the object instance and/or the corresponding 
database entities. As is known in the art, the metadata for the database may express that 
a given column holds integer values, character data, a reference to another database 
entity, etc. 

The XML access application 122 may be an XML editor or other tool that can 
create and/or present XML documents as described below. For example, an XML editor 
may be used to modify an XML document that was exported from one application, or 
another tool may be used to create an XML document consistently with a DTD. 

The active server pagel24, in an exemplary embodiment, is a Microsoft Active 
Server Page. The ASP 124 provides one way for accessing the applications by paths 
132, 134, whereas paths 106 and 108 provide another (in which information is passed to 
the applications as COM+ arguments). 

Logic 

Figure 2 is a flowchart showing the logic for exporting information according to 
a preferred embodiment of the invention. The logic starts 200, and with the assistance of 
the browser (114, Fig. 1) a user selects objects to be exported 205. In one embodiment, 
the ActiveX control (1 16, Fig. 1), with the assistance of auto-discovery techniques, 
gathers a list of the model object types (i.e., classes) that support export and/or import 
functionality. This list is then presented to a user to identify the types of objects that 
may be exported. The user may then select all objects of a given object type or just 
specific identified instances. The user also provides a filename in which an XML 
document representation of the model object data should be held. In response to the 
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selection, the Active X control (1 16, Fig. 1) locates the appropriate server application, in 
this example the first application (118, Fig. 1), and the client sends the export request 
210 as COM+ API arguments through the Active X control The server application (1 1 8, 
Fig. 1) validates that the request refers to valid database objects 215. The server 
application then accesses the relevant source database instance (126, Fig. 1) holding the 
information for the identified object, reads the information corresponding to the request, 
and writes that data 220 as an XML document (150, Fig.l). Once the exporting of 
information is completed, the first application (118, Fig. 1) returns 225 status 
information to the Active X control (116, Fig. 1). The status is then displayed 230 to the 
user via a browser (1 14, Fig. 1) to the user who initiated the exportation, and the logic 
ends 299. 

Figure 3 is a flow chart more specifically showing the logic of reading objects 

from a database and writing it as an XML document as described above. The logic starts 

300 and attempts to read 305 object data corresponding to the objects included in the 

client export request. As stated above, the client request may identify all or select 

objects of an identified object type, and an internal list representation of objects to be 

exported is constructed accordingly. The first, application (1 18, Fig. 1) then determines 

310 whether the identified object exists in the database to validate that portion of the • 

request, i.e., the portion corresponding to the validated object. If the identified object 

does not exist, the application updates 3 15 an error information data structure and 

determines 320 whether the client request has identified other objects to be exported. If 

the identified object exists in the database (see 310), the first application (1 18, Fig. 1) 

reads 325 a complete version of the object's data from the database (126, Fig. 1). This 

reading is explained in further detail below. The collected information is then formatted 

and written 330 into an XML document (130, Fig. 1). More specifically, the XML 

document has tags to mark the data, in which the tag labels correspond to the database 

entity information and in which the contents correspond to the actual table data. 

Depending on the data organization, the process of reading may require iteration . 

through the object data, and a check is made 335 to determine whether all the 

information of a given object being exported has been written to an XML document. As 

part of the exportation, other information is gathered and eventually reported, such as the 

number of records exported. If not all of the information has been gathered, the iteration 
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continues 330 to format the object data accordingly. If the object has been fully 
formatted and written to an XML document (130, Fig. 1), then a check is made 320 
whether the exportation request has been completed, i.e., whether there are other objects 
to be exported. If not, as outlined above, a subsequent data object in the request is 
selected and the processing continues as described above. If the exportation request has 
been completed the processing ends 399. 

The reading and formatting of the object data is greatly facilitated by layering the 
software over the model software. In particular, as outlined above the MES applications 
are composed of objects implementing the model provided by that application. These 
models include "get" and "set" functionality to get and set object state, following well 
known object-oriented programming convention. These gets and sets have the logic for 
accessing the underlying database as necessary and the get and set routines are published 
or otherwise known. 

A preferred embodiment builds on the above as follows. A new export class is 
defined as a derived class of the actual model class. As such, the new export class 
inherits all of the functionality defined in the actual model class, including the gets and 
sets just mentioned. The new class defines a constructor method (constructor methods 
are known in the art) in which an object identifier is passed in as a variable and used to 
get and initialize object data members with the information corresponding to that object 
identifier. Thus, when an instance of this new class is instantiated it will be constructed 
with the data corresponding to the object identifier. An instance of the new export class 
may then in this fashion be constructed, passing in the identifier of the object to be 
exported, and an export object will be created that will be initialized to contain member 
data corresponding to the object to be exported. In effect, this portion of the new export 
object is a copy of the actual model object. 

The new class also includes export method logic that creates the XML document 
in the following manner. Following the organization of the object's data in the database, 
an opening tag is written for the highest level database entity for that object, followed by 
the entities that that entity contains, which may be other entities or data. Closing tags 
and empty tags are inserted as appropriate, depending on the database contents. The 
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highest tag corresponds to the object class, and each other tag label corresponds to the 
label used in the database, i.e., the column name of a table. Appendix A shows an 
exemplary XML document created in this manner. In this example, 
"ENTITYDETAILS" corresponds to the object name or class, and the tags underneath 
correspond to the table column names. (This method is only called after other software 
writes prolog information to the document, identifying a corresponding DTD, a root 
element, and the like.) 

The creation of the export logic is greatly facilitated through the use of code 
generation. A conventional code generator may be used to do the following. The code 
generator is passed the object name or class (e.g., ENTITYDETAILS in the above 
example) along with the table name corresponding to that object name, and along with a 
description of other entities that that object inherits from (in other words, other tables 
that may be referenced from one of the object members). The generators "script 5 * uses 
the above to construct C++ code to do the following: 

1 . To call library primitives to write XML tags to a file (i.e., the one to hold the 
XML document) to start an XML element. The tag label will either be the passed 
in object name (for the highest level tag) or the column names of the table (which 
may be determined from the database's metadata). 

2. To nest the logic of (1) as appropriate to handle hierarchical arrangements, see, 
e.g., Appendix A in which a tag "ENTITY" follows "ENTITY DETAILS". 

3. To insert the appropriate calls to get, or obtain, the database values in the 
database table (i.e., this is done at the leaves of the structural relationship); 
referring to the example of Appendix A, after code is generated to make the calls 
to write the tag "<ENT_NAMESPACE>" code is generated to obtain the actual 
value at the specified table at the column "ENT_NAMESPACE" and to format 
the returned value accordingly to ASCII. 

4. To write closing tags as appropriate. 

The generation is facilitated in that the organization of the data is already known and 
expressed as database metadata. 

The database metadata may be used to also generate a DTD expression of the 
metadata as well and thus generate a DTD for the object type at issue. See Appendix B 
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for an exemplary DTD corresponding to the object data expressed in XML document of 
Appendix A. 

In some cases, the generated code (either export logic or DTD) may need 
developer modification because the database information is not easily translated into an 
XML form. For example, if the database information is a reference to another database 
entity, a developer may need to modify the automatically generated code to reflect and 
properly handle this type of entity. 

Using the above, when a model is changed by a developer he or she may need to 
run a utility to generate the code as outlined above and to modify the generated code as 
appropriate. Regardless, the interface to the export logic remains the same, i.e., the 
export methods, and thus the tool to export object data does not need to change when the 
model changes. Instead, the export tool needs to only instantiate an object from the new 
export class (derived from the object class to be exported) and to pass to the constructor 
the object identifier for the object to be exported. The instantiated object will thus 
automatically have all of the logic to obtain any data of interest. Once constructed, that 
object's (i.e., the one from the derived class) export method is invoked to write the XML 
data. As outlined above, this will write the XML file. The corresponding DTD file for 
this object type was created at the time the export logic code was generated. 

The exportation process at an object and class level is illustrated in Figure 6A, 
utilizing, in part, the known Booch notation. 

Under the above embodiment, a DTD is created to represent the object data 
expressed in the XML document holding exported data. The DTD may also be used by 
other tools (e.g., XML editor) to facilitate the modification of such an XML document 
(e.g., for subsequent import in another embodiment) or to create an XML document 
automatically. (For example, a DTD may first be created based on the database 
metadata, and the DTD form may subsequently be used by code generators to create the 
XML document write commands to insert the tag information.) Moreover, though the 
example of Appendix B uses conventional XML syntax to show that the entities are 
parsed character data (PCDATA), it will be appreciated that more restrictive forms of 
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DTDs may be written, e.g., other data forms, such as integer, defining sequence 
relationships, and the like. 

Figure 4 is a flowchart showing the logic for importing information according to 
the a preferred embodiment of the invention. The logic starts 400, and with the 
assistance of the browser (1 14, Fig. 1) a user selects objects to be imported 405 and 
specifies an importation policy, e.g., add information as specified in the request, or 
update information only if target database does not have the information. In response to 
the selection, the Active X control (116, Fig. 1) locates the appropriate server 
application, in this example the second application (120, Fig. 1) , and sends the import 
request 410 to that application. The importation request, among other things, identifies 
the XML document holding the data to be imported. This may be from the previously 
explained exportation process, an edited version thereof, or a document independently 
created. The server application (120, Fig. 1) validates 415 the XML document with 
reference to the DTD, i.e., that the XML document has the form defined in the DTD. 
The server application then accesses the XML document (130, Fig.l), processes the 
XML document data, and loads 420 the corresponding information into the identified 
target database instance (128, Fig. 1). Once the importing of information is completed, 
the second application (120, Fig. 1) returns 425 status information to the Active X 
control (1 16, Fig. 1). The status is then displayed 430 to the user via a browser (1 14, 
Fig. 1) to the user who initiated the importation, and the logic ends 499. 

Figure 5 is a flow chart more specifically showing the logic of loading objects 
into a database based on the information in an XML document. The logic starts 500 by 
reading 505 information from the client importation request represented, in part, by the 
XML document (130, Fig.l) and collecting sufficient information to identify a first 
selected object in the request. The second application (120, Fig. 1) then attempts to read 
5 10 the data corresponding to that object from the target database (128, Fig. 1). The 
software then determines 515 whether the identified object already exists in the target 
database. If it does exist, the application analyzes 520 the import policy specified in the 
client request to determine whether existing data should be over-ridden with the data 
from the XML document (130, Fig. 1). If the identified object exists in the database 
(see 515) and the client request indicates that the database information should not be 
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over-ridden (see 520) then the software iterates 525 through the XML document (130, 
Fig. 1) to determine if the document contains more data 525 for other objects to be 
imported. If either the identified object does not exist in the database (see 5 1 5) or if the 
client requested indicated that existing data should be over-ridden (see 520), the 
application reads 530 all of the information in the XML document (130, Fig. 1) 
corresponding to the identified object. The XML information collected for the document 
is validated 535 against the database. This validation in some cases will be more robust 
than that done at the DTD-level of validation. For example, with modern DTD, database 
metadata may be more restrictive than that expressible in DTD. Thus, the XML 
document may satisfy DTD validation but fail database validation. The application then 
determines 540 whether all of the data in the XML document is valid against the 
database metadata. If the data is not valid, the software accumulates 545 this error 
information in a data structure. If the data is valid, the software updates the target 
database (128, Fig. 1) with the object data compiled from the XML document This 
update 550 includes updating all of the information related to the updated object, for 
example, in the case of hierarchical objects referring to other data and objects. Then, as 
outlined above, the software iterates 525 through the XML document (130, Fig. 1) to 
determine if the document contains more data. If so, the process repeat as described 
above; if not, the update process ends 599. 

Similar to the export case described above, importation is facilitated by 
inheritance and code generation. Figure 6B illustrates the process. In analogous fashion 
to that described above, an import class is defined that is derived from the actual MES 
object class. The' derived class, like the case above, includes generated and modified 
code, which in this case has calls to library primitives to parse the XML document to 
collect table references, e.g., table name and columns, and to collect the actual data from 
the tag contents. The generated code also has the logic to write to the database as 
needed. In some cases, the XML contents will need to be converted to a different type, 
e.g., integer, and in some cases this conversion may need to rely DTD definition and/or 
the metadata definition. Like the above, this code may need developer modification, but 
also like the above changes to the model will not require changes to the import tool. 
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In this case, the instantiated object of the new class is passed the identifier for the 
object that should receive the data so that that object may be initiated appropriately. 
That object may then be invoked with "gets" to see what state it has (e.g., see above in 
conjunction with import policy) and with "sets" as needed. 

Figure 7 is a high-level diagram of a computer system that may be used for the 
client or servers shown in figure 1 . The system 700 includes one or more processors 
702, a memory 704 (potentially organized as virtual memory 706), display device 708, 
and input/out logic 710 in communication via a bus 712. 

The above embodiments offer several advantages. By way of example only and 
not limitation, the embodiments allow XML documents and DTD information to be used 
to express object data, even in embodiments where the database is not object oriented. 
This allows the object data to be validated (in a DTD sense) before it is imported. In 
addition besides being more understandable because they are self-describing data, XML 
and DTD documents use standards that facilitate the development of tools. In addition, 
the import and export utility does not need to change when the model changes and 
instead continues to work. Exportation and importation are greatly benefited and can be 
largely automated. Users do not need to develop custom scripts for export or import, nor 
do they need to enter vast amounts of information manually. The tools may be 
implemented with known internet and intranet technologies. XML also facilitates the 
support of internationalization of the information, i.e., so that the intermediary form may 
be presented in multiple languages. In addition, since XML documents are not 
necessarily physical files, the XML document intermediary form may also be used to 
perform exportation and- importation without having an intermediary file. 

Other embodiments may use forms other than XML as an intermediary form. 
For example, ASCII or SGML may be used to convey information in an organized way. 
In addition, the use of XML may foster the use of a specialized language based on XML 
that may also be used. Though a preferred embodiment layered import and export logic 
over the model by deriving classes from the model classes and adding import and export 
methods thereto, other approaches may be used. Among other things, the derived class 
may have both import and export methods for a given object type. In addition, the logic 
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may be layered in other ways so that they exploit the gets and sets of the model data yet 
provide a consistent interface to the tools so that the import and export utility does not 
need to change when the model changes. 

The exemplary embodiment above used Active X to convey client requests as 
COM + arguments, but other approaches may be substituted. For example, the browser 
may interact with the ASP page to invoke the applications as needed. The imports and 
export requests may then be performed through corresponding HTML pages. 

In general, it should be emphasized that the various components of embodiments 
of the present invention can be implemented in hardware, software or a combination 
thereof. In such embodiments, the various components and steps would be implemented 
in hardware and/or software to perform the functions of the present invention. Any 
presently available or future developed computer software language and/or hardware 
components can be employed in such embodiments of the present invention. For 
example, at least some of the functionality mentioned above could be implemented using 
the C, C++, or any assembly language appropriate in view of the processors) being 
used. It could also be written in an interpretive environment such as Java and 
transported to multiple destinations to various users. 

It is also to be appreciated and understood that the specific embodiments of the 
invention described hereinbefore are merely illustrative of the general principles of the 
invention. Various modifications may be made by those skilled in the art consistent with 
the principles set forth hereinbefore. 

Having described an exemplary embodiment, it should be apparent to persons of 
ordinary skill in the art that changes may be made to the embodiment described without 
departing from the spirit and scope of the invention. 

Appendix A 

<?xml version="1.0" standalone="yes"?> 
<!DOCTYPE ENTITYDETAILS SYSTEM "entity. dtd n [ 
<! — 

Description : 
Author : 

— > 
]> 
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<ENTITYDETAILS> 
<ENTITY> 

< ENT_NAME S PACE> FAB 3 0 0< /ENT_NAME S PACE> 

< ENT_NAME> CLN2 OK /ENT_NAME> 
<ENT_DATAGROUP/> 

<ENTJTPLJJAMESPACE>FAB300</ENTJTPLJJAMESPACE> 
<ENT_TPL_NAME>san_MasterEntityTemplate</ENT TPL NAME> 
<ENT_TPL_VERSI0N>1</ENT_TPL__VERSI0N> 
<0B JECT__STATUS> 1< /OB JECT_STATUS> 
<ENTJTYPE>Equipraent</ENT_TYPE> 

< DESCRIPTIONS 

< ENT_STATE> ENGINEERING /ENT_STATE> 

< PM_FLAG> 0< / PM_FLAG> 

< WORKFLOW_NS> FAB3 0 0< /WORKFLOW JNS> 

< WO RKFLO W_NM> An user f low</WORKFLOW_NM> 
<WORKFLOW_VER> 4< /WORKFLOW_VER> 

<BEHAVIORJlODEL_NS>FAB300</BEHAVIOR_MODELjqS> 
<BEHAVIOR__MODEL> san_test JMB< /BEHAVIOR_MODEL> 

< BEHAVIO R_MO DEL_VER> 1< /BEHAVIOR_MODEL VER> 

< PARENTIS /> "~ 
<PARENT_ENT/> 
<COMPONENT__ROLE/> 
<CHECKLIST_NS/> 

< CHECKL IS T_NAME /> 

<CHECKLIST_VER>0</CHECKLIST_VER> 
<ATTRIBUTES> 

< ATTRIBUTETYPE> 3< /ATTRIBUTET YPE> 
<ATTRIBCJTENAME> Equipment ID< /ATTRIBUTENAME> 

< ATTRIBUTEINDEX> 0< /ATTRIBUTE INDEX> 
<DESCRIPTION/> 

<KEEPHISTFLAG>K/KEEPHISTFLAG> 
<PUBLISHFLAG>0</PUBLISHFLAG> 
<RESTRICTRULE> 0< /RESTRICTRULE> 

< MAN DATO R Y FLAG> 0< /MANDATORYFLAO 
<NAMEDTYPEFLAG> 0< /NAMEDTYPEFLAO 
<NAMEDT YPENS /> 
<NAMEDTYPENAME/> 
<ATTRIBUTEVALUE/> 
<CDOSTRING> 03< /CDOSTRINO 

</ATTRIBUTES> 
<CATEGORIES> 

<CLASSIFTYPE>CSIM_ENTITY</CLASSIFTYPE> 

< NAME S PACE> FAB 3 0 0< /NAME S PACE> 
<NAME>Etech/Prc</NAME> 

</CATEGORIES> 
</ENTITY> 
<ENTITY> 

< E NT_NAME S PAC E> FAB 3 0 0< / ENT_N AME S PAC E> 

< ENT_NAME> CLN2 0 2< /ENT_NAME> 

< ENT_DATAGROUP/> 

< E NT_T P L__NAMES PACE> FAB 3 0 0< / ENT_T PL__NAME S PACE> 
<ENT_TPL_NAME>san_MasterEntityTemplate</ENT TPL NAME> 
<ENTJTPL_VERSION>K/ENT TPL_VERSION> " ~~ 
<OB JECT_jSTATUS> 1< /OB JECT_STATUS> 

< ENT_TYPE> Equipment < /ENT_TYPE> 

< DESCRIPTIONS 

< ENT_STATE> DOWN NON SCHED</ENT_STATE> 

< PM_FLAG> 0< / PM_FLAG> 
< WORKFLOW NS/> 
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<WORKFLOW_NM/> 

< WORKFLOW_VER> 0< /WORKFLOW VER> 

<BEHAVIOR_MODEL_NS>FAB300</BEHAVIOR_MODELJJS> 

<BEHAVIOR_MODEL>san_test_MB</BEHAVIOR_MODEL> 

<BEHAVIOR_MODEL_VER> 1< /BEHAVIOR MODEL VER> 

<PARENT_NS/> ~ ~ 

<PARENT_ENT/> 

<COMPONENTJ*OLE/> 

<CHECKLIST_NS/> 

<CHECKLIST_NAME/> 

<CHECKLIST_VER> 0< /CHECKLIST_VER> 

<ATTRIBUTES> 

<ATTRIBUTETYPE>3< /ATTRIBUTETYPE> 
<ATTRIBUTENAME> Equipment ID</ATTRIBUTENAME> 
<ATTRIBUTEINDEX>0< /ATTRIBUTE INDEX> 
<DESCRIPTION/> 

<KEEPHISTFLAG>K/KEEPHISTFLAG> 
<PUBLISHFLAG>0</PUBLISHFLAG> 

< RESTRI CTRULE> 0< / RESTRI CTRULE> 
<MANDATORYFLAG> 0< /MANDATORYFLAO 
<NAMEDTYPEFLAG> 0< /NAMEDTYPEFLAO 
<NAMEDT YPENS /> 
<NAMEDTYPENAME/> 
<ATTRIBUTEVALUE/> 
<CDOSTRING> 03< /CDOSTRINO 

</ATTRIBUTES> 
<CATEGORIES> 

<CLASSIFTYPE>CSIM_ENTITY</CLASSIFTYPE> 

< NAMES PACE> FAB 30 0< /NAMES PACE> 
<NAME>Etech/Prc</NAME> 

</CATEGORIES> 
</ENTITY> 
< /ENTIT YDETAILS> 
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Appendix B 

ENTITY. DTD - Document Type Definition for Entity. 

<! ELEMENT ENTITYDETAILS (ENTITY)* > 
<] ELEMENT ENTITY 

(ENTJNAMESPACE I ENT_NAME | ENTJDATAGROUP | ENT_T PL_NAMES PACE | ENT JT PL JNAME | EN 
T_TPL_VERSION | OB JECT_STATUs7eNTJTYPE | DESCRIPTION | ENT_STATE | PM__FLAG | WORK 
FLOW_NS | WORKFLOWJSM | WORKFLOW JVER I BEHAVIOR_MO DEL JNS | BEHAV IOR JMO DEL | BEHAV 
IOR_MO DELIVER | PARENTIS | PARENT_ENT I COMPONENT_ROLE | CHECKLIST NS | CHECKLIS 
T_NAME | CHECKLI STIVER | ATTRIBUTES | CATEGORIES ) * > 
ELEMENT ENT_NAMESPACE (# PCDATA)* > 
ELEMENT ENT_NAME (# PCDATA)* > 
ELEMENT ENT_DATAGROUP (# PCDATA)* > 
ELEMENT ENTJTPL_NAME SPACE {# PCDATA)* > 
ELEMENT ENT_TPL_NAME (# PCDATA)* > 
ELEMENT ENT_TPL__VERS ION (#PCDATA) * > 
ELEMENT OBJECT_STATUS (# PCDATA)* > 
ELEMENT ENTJTYPE (# PCDATA)* > 
ELEMENT DESCRIPTION (# PCDATA) * > 
ELEMENT ENT_STATE (# PCDATA)* > 
ELEMENT PM^FLAG (# PCDATA) * > 
ELEMENT WORKFLOWJflS ( # PCDATA) * > 
ELEMENT WORKFLOW_NM (#PCDATA)* > 
ELEMENT WORKFLOWJ/ER (# PCDATA)* > 
ELEMENT BEHAVIORJ40DELJJS (# PCDATA) * > 
ELEMENT BEH AVIO R_MO DEL (# PCDATA)* > 
ELEMENT BEHAVIO R_MO DELIVER (# PCDATA)* > 
ELEMENT PARENT_NS (# PCDATA)* > 
ELEMENT PARENT JENT (# PCDATA)* > 
<! ELEMENT COMPONENT_ROLE (# PCDATA)* > 
<! ELEMENT CHECKLIST_NS (# PCDATA)* > 
< ! ELEMENT CHECKLIST JIAME (# PCDATA)* > 
<! ELEMENT CHECKLI STIVER (# PCDATA)* > 
<! ELEMENT ATTRIBUTES 

(ATTRIBUTETYPE | ATTRIBUTENAME | ATTRIBUTEINDEX | DESCRIPTION | KEEPHISTFLAG | PU 
BLISHFLAG | RESTRICTRULE I MANDATORYFLAG | NAME DT Y PE FLAG | NAMEDTYPENS | NAMEDTYP 
ENAME | ATTRIBUTEVALUE | CDOSTRING) * > 
< ! ELEMENT ATTRIBUTETYPE (# PCDATA)* > 



ELEMENT ATTRIBUTENAME (# PCDATA)* > 
ELEMENT ATTRIBUTEINDEX {# PCDATA)* > 
ELEMENT KEEPHISTFLAG (# PCDATA)* > 
ELEMENT PUBLISHFLAG (# PCDATA)* > 
ELEMENT RESTRICTRULE (# PCDATA)* > 
ELEMENT MANDATORYFLAG (# PCDATA)* > 
ELEMENT NAMEDTYPEFLAG (# PCDATA)* > 
ELEMENT NAMEDTYPENS (# PCDATA)* > 
ELEMENT NAMEDTYPENAME {# PCDATA)* > 
ELEMENT ATTRIBUTEVALUE {# PCDATA)* > 
ELEMENT CDOSTRING (# PCDATA)* > 

ELEMENT CATEGORIES ( CLASS I FT Y PE | NAMESPACE | NAME) * > 
ELEMENT CLASSIFTYPE (# PCDATA) * > 
ELEMENT NAMESPACE {# PCDATA)* > 
ELEMENT NAME (# PCDATA)* > 



What is claimed is: 
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1 . An MES application on a computer readable medium, the MES application 
having at least one model object, the data therefor persistently stored on a database, and 
wherein the one model object includes logic to receive an XML expression of model 
object data and to load the XML-expression of the data in the database. 

2. The MES application of claim 1 wherein the logic to receive an XML expression 
includes logic to receive an importation policy for specifying whether or not database 
data should be over-ridden with the XML-expression data and logic to load the XML- 
expression if the policy states that database data should be over-ridden 

3. The MES application of claim 1 wherein the logic to receive and to load includes 
logic to parse the XML expression and to convert XML tag labels to database address 
information, and to convert XML element contents to database values. 

4. The MES application of claim 1 wherein the at least one model object is 
constructed from a class that is derived from an MES model object class, and wherein 
the class so derived inherits all functionality from the MES model object class and 
wherein the class further includes import method logic to receive an XML expression of 
model object data and to load the XML-expression of the data in the database. 

5. An MES application on a computer readable medium, the MES application 
having at least one model object, the data therefor persistently stored on a database, and 
wherein the one model object includes logic to create an XML expression of model 
object data in the database. 

6. The MES application of claim 5 wherein the logic to create includes logic to 
create XML tag information from database reference information for the database entity 
holding the model object data, and logic to retrieve the model object data from the 
database and to insert the retrieved data as XML element contents. 

7. The MES application of claim 1 wherein the at least one model object is 
constructed from a class that is derived from an MES model object class, and wherein 
the class so derived inherits all functionality from the MES model object class and 
wherein the class further includes export method logic to create an XML expression of 
model object data in the database. 
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8. A method of importing data into an MES application haying at least one model 
object, comprising: 

a. forming an XML expression of the object data; 

b. sending the XML expression to the MES application; 

c. the MES application parsing the XML expression to determine the object type, 
the object parts, and the object data values; 

d. the MES application loading the determined object type, the object parts, and the 
object data values into a database corresponding to the MES application. 



9. The method of claim 8 further comprising 

forming a DTD expression of the object class definition; 
validating the XML expression against the DTD expression. 



1 0. A method of exporting object data in which a model object has data stored in a 
database, comprising: 

a. forming XML tag labels from database address information for the object data to 
be imported; 

b. accessing the database to obtain the values of the stored object data; 

c. using the retrieved values as contents for the XML element corresponding to the 
stored object data; 

d. providing an XML document created from (a)-(c) as an exported version of the 
model object data. 

1 1 . The method of claim 6 further comprising creating a DTD expression of the 
object class definition for the object to be exported. 

12. An MES application on a computer readable medium, the MES application 
having at least one model object, the data therefor persistently stored on a database, and 
wherein the application has import logic layered over the model object, wherein the 
import logic defines an external interface for loading model object data, and wherein the 
import logic includes logic to invoke the model object to load the model object data into 
the database. 
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13. An MES application on a computer readable medium, the MES application 
having at least one model object, the data therefor persistently stored on a database, and 
wherein the application has export logic layered over the model object, wherein the 
export logic defines an external interface for obtaining model object data, and wherein 
the export logic includes logic to invoke the model object to obtain the model object data 
from the database. 

14. A manufacturing execution system (MES), comprising: 

a client computer having a user interface providing a control for exporting or 
importing selected model objects of the MES and for constructing a client request to 
request export or import of selected objects; and 

a server computer having the MES application executing thereon, the MES 
application organized as a relationship of model objects, with each model object having 
data therefor stored in a database, wherein the application includes import and export 
logic, responsive to the client request, for forming an XML expression of model object 
data in response to an export request, and for loading data expressed in XML form into 
the database in response to an import request. 
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